A typical business utilizes an accounting software system (or an accounting module to its enterprise resource planning system or other database systems) that maintains a database of the business' transactions with its customer, vendors, employees, banks, and other third parties associated with the business. Such accounting systems are typically architected as a transaction database wherein data is input into the system through predefined transactions and extracted from the system utilizing database reporting modules.
In the early accounting systems, payments to third party payees were effectuated entirely outside of the accounting software system. An appropriately authorized operator would utilize a reporting module to obtain a listing of payments to be made to various payees. The operator would then issue a payment draft or check to each payee either by manually filling in payment information in a pre-printed draft form or by entering the payment into a secure check printing software system which, in turn, prints each draft on either a pre-printed form or on blank check stock. After the drafts are printed, the operator will enter one or more payment transactions into the accounting system to indicate that the payments have been issued.
With advanced payment management solutions, the accounting system may output a payments file which includes a plurality of records, each reflecting a payment to be issued. An appropriately authorized operator would import the payments file to the payments management solution. A check printing module of the payments management solution prints a draft corresponding to each record within the payments file on either a pre-printed form or on blank check stock. After the drafts are printed, the operator will typically enter only a single acknowledgement transaction into the accounting system to indicate that all payments within the payments file have been issued.
More advanced solutions may support electronic fund transfer payments. More specifically, the payments management solution may receive a payments file from the accounting system and generate a plurality of electronic fund transfer transactions for execution by an applicable financial institution.
When an electronic fund transfer transaction file is transferred to a financial institution, there is a well recognized need for the financial institution to be assured that the transaction file is accurate and appropriately authorized. One known solution utilized for assuring that a transaction file is accurate and appropriately authorized is a system utilized by the Bankers Automated Clearing System (BACS) and referred to as BACSTEL IP. In the BACSTEL IP system, a member financial institution (or some other trusted certificate authority) issues a digital certificate—which binds a public key of an asymmetric key pair to a user who is known to have the authority to authorize electronic fund transaction payments (e.g. an authorized user). The digital certificate and the private key of the key pair is securely stored on a smart card or other hardware key that is issued to the authorized user.
The authorized user runs a BACSTEL IP digital signature software component on his or her computer along with a program for interfacing with the financial institutions BACSTEL IP systems and an interface to a smart card reader.
The digital signature software component receives a data file from a higher level system and performs the following processes. First, the component performs a first SHA-1 hash of the data file to generate a 160-bit string commonly known as a digest. An SHA-1 hash is a well known secure hash algorithm developed by the National Institute of Standards and Technology which is useful for generating a 160-bit hash of any data file with a size up to 264 bits in length. The component then combines the digest with other message attributes such as the current date and attribute type. The combination is referred to as the authenticated attributes. The authenticated attributes are then SHA-1 hashed to generate a second 160-bit hash string. The second 160-bit string is passed to the user's smart card. The smart card returns a digital signature of the 160-bit string along with the user's digital certificate and certificate chain. The component then generates a data structure known as a PKCS#7 which includes the digest, the digital signature, and the authorized user's digital certificate and certificate chain. The PKCS#7 and the electronic fund transfer transaction file are then passed to the BACSTEL IP systems.
The smart card, in conjunction with its PC resident driver code, comprises executable code which receives data for digital signature, prompts the authorized user to input a secret PIN number for authentication, and, in response to receiving the correct PIN number, returns a digital signature of the file along with the user's certificate and certificate chain.
When an authorized user is ready to submit an electronic fund transfer file to the BACSTEL system, the following process is used to assure that the transaction file is accurate and appropriately authorized.
First, the user's system presents the electronic fund transfer transaction file to the digital signature software component. As discussed above, the component will return a PKCS#7 data structure which includes a digest of the transaction file, a digital signature of the authenticated attributes, and the user's digital certificate and certificate chain.
The user's system then establishes a secure socket layer (SSL) connection to the financial institution's BACSTEL system. After the SSL connection is established, the BACSTEL system provides an authentication challenge to the user's system. The authentication challenge includes a randomly generated message.
Upon receipt of the authentication challenge, the user's system presents the random message to the digital signature software component which returns a digital signature and the user' digital certificate and certificate chain. These are passed back to the BACSTEL system.
After receiving an indication that the BACSTEL system has authenticated the user (the digital signature is that of the authorized user identified in the digital certificate), the user's system presents the PKCS#7 data structure and the transaction file to the BACSTEL system.
The financial institution can verify the integrity of the transaction file by verifying the signature (e.g. calculating a hash of the authenticated attributes for comparison to the result of decrypting the digital signature). If the digital signature is valid, the bank is assured that the transaction file presented to the BACSTEL system is the same transaction file presented to the digital signature software component.
There exists a desire in the industry to manage payments utilizing a payments solution located on a centralized server that is accessible by remote thin client devices over open networks such as the Internet. This client server architecture retains all data on the centralized server resulting in the payment data being more secure and more easily audited. Further, the entire payment solution being located on a centralized server is more easily maintained than multiple remote systems.
The problem with the above described digital signature solution is that it requires that the entire transaction file be located on the user's system so that it can be presented to the digital signature software component. This creates at least one problem.
If the transaction file is originally generated on a centralized server, the entire transaction file must be transferred to the remote client for digital signature. If the file is large, transferring the file can require significant network bandwidth and/or significant down load time if the user's connection is at a low data rate—such as dial-up. Further, transferring the transaction file to the remote client opens additional opportunities for a security breach as the transaction file may be inadvertently (or intentionally) stored in an insecure location on the remote client. Further yet, transferring the transaction file to the remote client creates audit issues as it would be possible to alter the transaction file on the user's system prior to digital signature and presentation to the BACSTEL system.
What is needed is a payments management system that includes a server and thin client architecture and enables a remote approver to authorize a payments file in a manner that does not suffer the disadvantages of transferring a transaction file to a user's remote system.